Balance between Formal and Informal Methods, Engineering and Artistry, Evolution and Rebuild

This paper is the result of a workshop entitled “Software Reliability for FCS” that was organized by the Army Research Office, held on May 18-19, 2004, and hosted by: Institute for Software Integrated Systems (ISIS), Vanderbilt University. I was given the charge of leading one of four topic areas, and was assigned the title. This is my summary of the results of the workshop on this topic. It may well be that established approaches to software engineering will not be sufficient to avert a software disaster in FCS and similarly ambitious, software-intensive efforts. This topic examines the tension between informal methods, particularly those that focus on the human, creative process of software engineering and the management of that process, and formal methods, specifically those that rely on mathematically rooted systems theories and semantic frameworks. It is arguable that, as these approaches are construed today by their respective (largely disjoint) research communities, neither offers much hope of delivering reliable FCS software. Although certainly these communities have something to offer, the difficulties may be more deeply rooted than either approach can address. In this workshop, we took an aggressive stand that there are problems in software that are intrinsically unsolvable with today’s software technology. This stand asserts that no amount of process will fix the problems because the problems are not with the process, and that today’s formal techniques cannot solve the problem as long as they remain focused on formalizing today’s software technologies. A sea change in the underlying software technology could lead to more effective informal and formal methods. What form could that take? 1. Some Objectives of Formal Methods An early conclusion in the workshop was the dispelling a widely held misconception that formal methods have had little practical impact in software. Type systems are an example of a formal method that is a centerpiece of all modern programming languages. They have a formal structure that has influenced the design of languages and compilers and has proven scalable to extremely large programs. They contribute enormously to software reliability and to the efficiency of the software design process by exposing many programming errors early in the design process. But type systems represent only the static structure of programs. They do not represent temporal or concurrent behavior, for example. Could the equivalent of strongly typed interfaces be developed to represent these other aspects? While there is research in this direction, it appears inconclusive at this time. Nonetheless, many formal methods demand a level of skill levels not normally found in software development community to apply. An examination reveals that formal methods have several objectives, and that depending on the emphasis, the approaches may differ. In particular, formal methods have been proposed to provide: • semantic grounding for languages, • precise specification, • proof of properties, • proof of correctness, • improved understanding, and • reduced need for testing. It was argued in this workshop that of these, “proof of correctness” was probably the only unattainable objective. 2. Programming Languages Languages form the medium of expression for software design. In practice, most embedded software is written in C, an ironic choice because of its complete lack of concurrent or temporal semantics. Concurrency and time are essential aspects of software that engages with sensors and actuators. What C does provide is excellent efficiency, access to hardware resources, and familiarity to programmers. Can new languages help with embedded systems? An interesting case study is the SCADE system marketed by Esterel Technologies. This system is based on the synchronous language Lustre, the formal properties of which strongly influenced the process that led to the certification of the compiler for use in safety critical avionics software. This system is used in practice by Airbus and others for embedded software design. Another interesting case study is Simulink, from The MathWorks. Simulink has taken hold in several communities, perhaps most notably in the automotive industry where it is widely used to design and deploy embedded control software. An issue that arises is that the introduction of new programming languages is difficult, expensive, and risky. Even with a strong mandate for many years from DOD, Ada, which has many desirable features for embedded software, has never been completely embraced by the embedded software community. A focus on domain-specific languages and on languages with visual syntaxes (SCADE and Simulink fit both) helps languages gain acceptance, because domain knowledge and style can be built into the languages, and visual syntaxes meet less resistance, presumably because the learning curve appears gentler (although in practice, it may be just as steep). Yet the success of Simulink and SCADE is the exception, not the rule. Simulink succeeds in part because it is not recognized by engineers as a “language.” It is, first and foremost, a modeling tool. It just happens to be extremely convenient that models can be compiled (“code generated”) into deployable code. Whereas modeling has traditionally been used as part of the requirements definition process, in this case the requirements turn out to be a compilable implementation. The distinction between “model” and “program” disappears. Neither Simulink nor SCADE emerged from the mainstream programming languages research community. It was argued in the workshop that language research is stalled in part because language researchers tend to promote “universal” solutions, languages that completely replace their predecessors. Simulink most notably does not do this; it fully embraces C as a mechanism for defining primitive components and as a target for code generation, and therefore offers the key advantages of C, access to hardware resources and code efficiency, but offers them within a framework that has a clean semantic notion of time and concurrency. Simulink also leverages the task scheduling provided by real-time operating systems (RTOS’s), but does not expose to the designer the features that are difficult to use correctly, such as priorities. Priorities are used by the code generator (with preemptive multitasking) to synthesize a correct implementation of the Simulink semantics, but what the designer works with is the Simulink semantics, not the abstraction of processes with priorities that RTOS’s depend on.